デジタルアイデンティティワーキンググループミニウェビナー第4回「IaaSとアイデンティティ」に登壇しました

コンバンハ、千葉（幸）です。

2023年2月22日（水）に行われた、日本ネットワークセキュリティ協会（JNSA）が主催するウェビナー「？？？とアイデンティティ」 第4回「IaaSとアイデンティティ」に登壇しました。

• JNSAデジタルアイデンティティWG

「？？？とアイデンティティ」は、日本ネットワークセキュリティ協会が主催する企業・組織のIT環境とアイデンティティの関わりについて様々な知見や技術を共有するイベントです。第4回は IaaS をテーマに、オンプレミス環境では存在しなかったシステムレイヤが増えたことによるアイデンティティへの影響、等々をメイントピックに据えたものでした。

このブログでは、簡単にウェビナーの概要のご説明と、自身の登壇分に関する補足を行います。

登壇者

• MC：
  • 佐藤 公理 氏（SailPointテクノロジーズジャパン合同会社）
• パネリスト：
  • 菊池 周平 氏（CyberArk Software 株式会社）
  • 千葉 幸宏（クラスメソッド 株式会社）

登壇動画

ウェビナーの概要は以下のとおりです。

大項目	小項目	メインスピーカー	動画
オープニング	ウェビナー紹介、パネリスト紹介	3名	0:00~
IaaSとアイデンティティの関係	IaaSにおける新たなアイデンティティの観点	千葉	7:11~
〃	多様化するクラウド利用環境とアイデンティティ	菊池 氏	15:15~
〃	サイバー攻撃を防ぐには？	菊池 氏	18:33~
IaaSでの人とモノのアイデンティティの違い	よくあるインシデント事例	菊池 氏	22:48~
〃	モノによるアクセスIDの問題点と必要なアクション	菊池 氏	28:35~
〃	アプリケーション内埋め込みID・パスワードの〓〓 *1	菊池 氏	30:26~
AWSでのアイデンティティ・セキュリティ	AWSにおけるアイデンティティ	千葉	37:01~
クラウド化が進むIT環境で今後のIaaSとアイデンティティはどうなる？	ディスカッション	3名	56:47~

登壇資料

わたしが話すときに画面投影していた資料です。（お二方の投影分は対象外です。）

IaaS における新たなアイデンティティの観点

「オンプレミスで物理サーバーを稼働させる場合」と「IaaS として仮想サーバーを利用する場合」で、アイデンティティの観点の差異を考えました。

OS 以上のレイヤにおけるアイデンティティ、例えば OS ユーザー、ミドルウェアユーザー、アプリケーションユーザーについては、両者に特徴的な差異はありません。それより下のレイヤ、言ってみればクラウドのレイヤで追加のアイデンティティを考慮する必要があります。

データプレーンとコントロールプレーンという考え方をすると理解がしやすくなるかと思います。今回の例で言えば、データプレーンは言ってみれば仮想サーバーそのものです。コントロールプレーンからのリクエストに応じてデータプレーン上に仮想サーバーがデプロイされ、コンピューティング領域を利用可能となります。

クラウドサービスの利用者が仮想サーバーのスペック変更、パラメータの変更などを行いたい場合、そのリクエストはコントロールプレーンに送信します。クラウドサービスで用意されている専用のエンドポイントに Web API リクエストを送信し、そのリクエストに応じてクラウドサービス側でコントロールプレーンでの処理が決定され、その内容に応じてデータプレーンに変更が加えられる、という考え方です。

ここで、コントロールプレーンに対してリクエストを送るアイデンティティのことを考える必要があります。これが先述した「クラウドのレイヤでの追加のアイデンティティ」に該当します。例えば AWS で言えば IAM ユーザー/ロールというリソースが用意されているため、IaaS として AWS のサービスを利用する際には必ず考慮する必要があります。

AWS におけるアイデンティティ

クラウドサービスにおけるアイデンティティとして、今回は AWS を利用するケースを想定して取り上げました。主要な概念として以下を挙げました。

• AWS アカウント（箱）
• IAM ユーザー（ID）
• IAM グループ（ユーザーが所属するグループ）
• IAM ポリシー（権限の定義）
• IAM ロール（一時的に使える権限の固まり）

クラウドサービスによってこの辺りは考え方がガラッと変わる部分でもあります。

ヒトが使うアイデンティティ

アイデンティティを利用するのはヒトかモノか、という考え方ができます。ヒトが使うアイデンティティとしては IAM ユーザーと IAM ロールが考えられます。

少しスライドの表現を誤ったな、と反省したのですがモノも同じように IAM ユーザーや IAM ロールを利用できます。ただし、使用するインターフェースとしてはプログラムアクセスにほぼ限定されます。ヒトであれば管理コンソールもプログラムアクセスも両方使用できます。

ウェビナーでは先行して菊池氏が AWS IAM アクセスキーの流出というインシデントを取り上げていました。永続的なアクセスキーの払い出しはできるだけ避ける、各種認証情報をどう保護するか、というセキュリティの観点はアイデンティティの管理と切り離せないな、と改めて感じました。

マルチアカウント管理

先行して「AWS アカウントは各種リソースを格納する箱のようなもの」という表現をしました。利用規模が増えてくると、この箱がたくさん出来上がることになります。

IAM ユーザー・IAM ロールといった IAM リソースもどこかの箱に格納する必要があるので、規模が増えてくるとマルチアカウントにおけるアイデンティティ管理を考慮する必要が出てきます。

ここではひとまず、一定規模の環境では AWS アカウントごとに IAM ユーザーを用意するような管理の仕方は避け、必要時に IAM ロールを借り受ける構成（いわゆるスイッチロール）をとりましょう、という話をしました。そうすることで、それぞれの箱に永続的な認証情報を抱えることを避けられます。

さらにはシングルサインオンを導入するような構成も取りうるのですが、話が枝葉に寄っていってしまうと判断し割愛しました。

関連

今回わたしが話したことに関連性が強いエントリをいくつかご紹介します。

AWS IAM について詳細に取り上げたエントリです。執筆当時は「コントロールプレーンとデータプレーン」という表現を思い付いていなかったのですが、似たようなことを書いています。

AWS、Google Cloud、Azure におけるアカウントの考え方の差異をまとめたエントリです。クラウドサービスによってアカウントの考え方が異なり、ひいてはアイデンティティ管理の仕方も変わるのだろうと想像します。

AWS におけるマルチアカウントのパターンをまとめたエントリです。今回のウェビナーで取り上げた構成に該当するのは「アクセス手段『IAMユーザーからスイッチロール』」パターンです。

終わりに

デジタルアイデンティティワーキンググループミニウェビナー第4回「IaaSとアイデンティティ」の登壇内容のご紹介でした。

AWS IAM という概念が当たり前ではない前提で登壇内容を考えたので、改めてアイデンティティについて考え直すいい機会となりました。「ユーザー」「アカウント」「ID」といった言葉を用いた時に、その人のバックグラウンドによって思い浮かべる概念が変わりうる、というのは新鮮な気づきでした。なるべくイメージがずれないよう「AWS アカウントは箱」といった表現をしてみたりしたのですが、うまく理解につながっていればと思います。

CyberArk Software さんが強みを持つ特権 ID 管理製品についても興味深く拝聴しました。AWS IAM のアクセスキーを GitHub にあげてしまう、という事象がよくあるインシデント例として取り上げられていたので、やはりあるあるなんだな、と感じました。興味を持った方は以下もあわせて読んでいただければと思います。

ウェビナーの内容がなんらかみなさまの参考になれば幸いです。

以上、 チバユキ (@batchicchi) がお送りしました。

脚注